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REMOTE IMAGE CAPTURE WITH service companies store the information from paper receipts 

CENTRALIZED PROCESSING AND ar >d documents acquired from their customers on microfilm 

STORAGE or compact disc read only memory (CD-ROM) at a central 

facility. Customers typically deliver the paper receipts and 

CROSS-REFERENCE TO RELATED 5 documents to the central facility. For sensitive documents 

APPLICATIONS which cannot leave the customer site, some data archive 

service companies perform data acquisition and transfer to 

This application is a continuation in part of application magnetic tapes at the customer site and deliver the tapes to 

Ser. No. 08/917,761 filed Aug. 27, 1997, now U.S. Pat. No. the central facility. 

5,910,988. Th e approach offered by these data archive service com- 
panies have disadvantages. First, the approach is costly and 

FIELD OF THE INVENTION has poor performance because it requires an expensive, time 

This invention relates generally lo the automated process- =°™ng physical transportation of paper receipts or mag- 

ing of documents and electronic data from different appli- " etlc u ta P c u s from thc u Corner site to the central fachty. 

cations including sale, business, banking and general con- 15 f ur , ther ' ' he appr ° ac , h 15 not information can be 

sumer transactions. More particularly, it pertains to an lost or damaged during physical transportation. The 

automated system to retrieve transaction data at remote a fP roach ako has ,lmU6d ca P ab ' ul y 35 11 does not P rocess 

locations, to encrypt the data, to transmit the encrypted data «!«*«»"" record * a '°°6 with the paper receipts within a 

to a central location, to transform the data to a usable form, sin & Q system. 

to generate informative reports from the data and to transmit 20 0ther a PP roaches have focused on the elimination of 

the informative reports to the remote locations. P a P er rccci P ts and documents. U.S. Pat. No. 5,590,038 

discloses a universal electronic transaction card (UET card) 

BACKGROUND or smart card which stores transaction information on a 

memory embedded on the card as a substitute for a paper 

Hiis invention involves the processing of documents and receipL Similarly, U.S. Pat. No. 5,479,510 discloses a 

electronic data which are generated, for example, from sale, method of electronically transmitting and storing purchaser 

business and banking transactions including credit card information at the time of purchase which is read at a later 

transactions, smart card transactions, automated teller timc to ensure that thc purch ased goods or services are 

machine (ATM) transactions, consumer purchases, business delivered to the correct person 

forms, W2 forms, birth certificates, deeds and insurance ^ while these approacnes avoid tne prob i ems associated 

ocumen s. p a p er receipt they have other disadvantages. First, 

The enormous number of paper and electronic records these approaches do not offer independent verification of the 

generated from documents and electronic data from sale, accuracy of the records maintained by consumers, mcr- 

business and banking transactions contain valuable infor- chants and bankers with a third party recipient of the 

mation. First, these paper and electronic records contain 3S transaction data. For example, if a UET card is lost, stolen, 

information which can be used to verify the accuracy of the damaged or deliberately altered by an unscrupulous holder 

records maintained by consumers, merchants and bankers. after recording sale or banking transactions, these 

For example, customers use paper receipts of sale and approaches would not be able to verify the remaining 

banking transactions to verify the information on the peri- records which are maintained by the other parties to the 

odic statements which they receive from their bank or credit transactions. 

card institution. Merchants use paper receipts to record sale Next) tnese approaches do not have the ability to process 

transactions for management of customer complaints. Tax- botn paper and electronic records of transactions within a 

payers use paper receipts to record tax deductible contnbu- single) comprehensive system. Accordingly, they do not 

tions for use in their tax return preparation. Employees use ad dress the task of processing the enormous number of 

paper receipts to record business expenses for preparation of 45 paper receipts which navc becn generat ed from sales and 

business expense forms. banking transactions. The absence of the ability to process 

Paper and electronic records also contain information both paper and electronic records of these approaches is a 

which can be used for market analysis. For example, manu- significant limitation as paper receipts and documents will 

facturers and retailers can determine consumer preferences continue to be generated for the foreseeable future because 

in different regions as well as trends in consumer preferences 50 of concerns over the reliability and security of electronic 

from the information contained in paper and electronic transactions and the familiarity of consumers and merchants 

records. with paper receipts. 

However, the maintenance and processing of paper and These approaches also have a security deficiency as they 
electronic records presents difficult challenges. First, paper do not offer signature verification which is typically used on 
receipts and documents could easily be lost, misplaced, 55 credit card purchases to avoid theft and fraud. For example, 
stolen, damaged or destroyed. Further, the information con- a thief could misappropriate money from a UET card holder 
tained in these paper and electronic records cannot be easily after obtaining by force, manipulation or theft the user's 
processed because it is scattered among individual records. personal identification number (PIN). Similarly, it is not 
For example, the market trend information contained in a uncommon for criminals to acquire credit cards in victims' 
group of sales records retained by merchants cannot easily 6u names and make unlawful charges after obtaining the vic- 
be determined since this information is scattered among the tim's social security number. This becomes a greater con- 
individual records. Likewise, the tax information contained cern as that type of personal information becomes available, 
in a group of paper receipts of sales transactions retained by e.g., on the internet. Also, the signature verification per- 
consumers cannot easily be processed. formed manually by merchants for credit card purchases 

Previous approaches have been proposed to meet the 65 frequently misses forged signatures, 

challenges associated with the maintenance and processing Even if smart cards or UET cards had the ability to store 

of paper and electronic records. For example, data archive signature and other biometric data within the card for 
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verification, the system would still have disadvantages. It is a further object of the DataTreasury™ System to 

First, the stored biomctric data on the card could be altered employ a scanner and a data entry terminal at a customer site 

by a card thief to defeat the security measure. Similarly, the to retrieve data from paper transactions and to enable 

biornetric data could be corrupted if the card is damaged. additions or modifications to the scanned information 

Finally, the security measure would be costly at it would 5 respectively. 

require an expensive biornetric comparison feature either on It is a further object of the DataTreasury™ System to 

each card or on equipment at each merchant site. provide an input device for retrieving transaction data from 

Additional biornetric verification systems including sig- the memory of smart cards for independent verification of 

nature verification systems have been proposed to address the records maintained by consumers, merchants and bank- 

the security problem. For example, U.S. Pat. No. 5,657,393 10 ers to prevent the loss of data from the loss, theft, damage 

discloses a method and apparatus for verification of hand- or deliberate alteration of the smart card, 

written signatures involving the extraction and comparison 11 is a further object of the DataTreasury™ System to 

of signature characteristics including the length and angle of retrieve and process transaction data from DataTreasury™ 

select component lines. In addition, U.S. Pat. No. 5,602,933 System anonymous smart cards which are identified by an 

discloses a method and apparatus for the verification of 15 account number and password. Since DataTreasury™ Sys- 

remotely acquired data with corresponding data stored at a tem anonymous smart card transactions can be identified 

central facility. without the customer's name, a customer can add money to 

However, none of these verification systems offer general the DataTreasury™ System anonymous smart card and 

support for transaction initiation, remote paper and dec- make ex P e nditures with the card with the same degree of 

ironic data acquisition, data encryption, data 20 pnvacy as cash acquisitions and expenditures, 

communication, data archival, data retrieval, data mining, U 15 a further ob J ect of the DataTreasury™ System to 

manipulation and analytic services. Accordingly, there is a retneve customer billing data from employee time docu- 

need for a single system which offers comprehensive sup- raeDts and to S enerate customer billing statements from the 

port for the tasks involved in the automated processing of billing data. 

documents, biornetric and electronic data from sale, 25 . }\ 15 a further ob J ect of DataTreasury™ System to 

business, banking and general consumer transactions. miUate electronic transactions including transactions on the 

Further, there is a need for a single comprehensive system ! nternet and to P rovide identification verification by captur- 

having the reliability, performance, fault tolerance, capacity, in 8 and comparing signature and biornetric data, 

cost and security to satisfy the requirements of the retail, II ,s a further ob J ect of tnc DataTreasury™ System of the 

business, banking and general consumer industries. 30 invention to process electronic and paper transactions with 

a tiered architecture comprised of DataTreasury™ System 

SUMMARY OF THE INVENTION Access Terminals (DATs), DataTreasury™ System Access 

The invention provides an automated, reliable, high Collectors (DACs) and DataTreasury™ System Processing 

performance, fault tolerant, and low cost system with maxi- Concentrators (DPCs). 

mal security and availability to process electronic and paper 3S BRIEF DESCRIPTION OF THE DRAWINGS 

transactions, and has been named the DataTreasury™ Sys- ^ , . „ „ 

tem These and other objects and features of the invention will 

Itisanobjectofthepresentinventionloprovideasystem * more clearl y "n.^od from the following detailed 

for central management, storage and verification of remotely J? cr, P" on alon 8 Wlth the ^P^^g drawin 8 

captured electronic and paper transactions from credit cards, c cln ' 

smart cards, debit cards, documents and receipts involving F,G ; 1 ,V block diagram showing the three major 

sales, business, banking and general purpose consumer °P<*a"°™l elements of the invention: the DataTreasury™ 

applications comprising- System Access Terminal (DAT), the DataTreasury™ System 

at least one remote data access subsystem for capturing Access Col ' ec,or < DAC ) an D d ' he DataTreasury™ System 

and sending electronic and paper transaction data; 45 Concentrator (DPC); 

at least one data collecting subsystem for collecting and \ K . a bl ° ck dia S ram of ,be DAT architecture; 

sending the electronic and paper transaction data com- ™ G - 3a 18 4 flow chart describing image capture by a 

prising a first data management subsystem for manag- > 

ing the collecting and sending of the transaction data; FIG - 3b displays a sample paper receipt which is pro- 

at least one central data processing subsystem for 50 cessed bv tne 

processing, sending and storing the electronic and FIG - 4 ^ a block diagram of the DAC architecture; 

paper transaction data comprising a second data man- FIG. 5 is a flow chart describing the polling of the DATs 

agement subsystem for managing the processing, send- by a DAC; 

ing and storing of the transaction data; and FIG. 6 is a block diagram of the DPC architecture; 

at least one communication network for the transmission 55 FIG. 7 is a flow chart describing the polling of the DACs 

of the transaction data within and between said at least by the DPC; 

one data access subsystem and said at least one data FIG. 8 is a flow chart describing the data processing 

processing subsystem. performed by the DPC; and 

The DataTreasury™ System processes paper and/or elec- FIG. 9 is a flow chart describing the data retrieval 

tronic receipts such as credit card receipts, Automated Teller 60 performed by the DPC; and 

Machine (ATM) receipts, business expense receipts and FIG. 10 is a flowchart describing the use of the D at aTre a - 

sales receipts and automatically generates reports such as sury TM system to process personal checks, 
credit card statements, bank statements, tax reports for tax 

return preparation, market analyses, and the like. DETAILED DESCRIPTION OF THE 

It is a further object of the DataTreasury™ System to 65 PREFERRED EMBODIMENT 

retrieve both paper and electronic transactions at remote FIG. 1 shows the architecture of the DataTreasury™ 

locations. System 100. The DataTreasury™ System 100 has three 
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operational elements: the DataTreasury™ System Access information with machine readable data which is encoded 

Terminal (DAT) 200 (the remote data access subsystem), the into many, tiny, individual glyph elements. Each glyph 

DataTreasury™ System Access Collector (DAC) 400 (the clement consists of a 45 degree diagonal line which could be 

intermediate data collecting subsystem), and the DataTrea- as short as 1/1 00th of an inch depending on the resolution of 

sury™ System Processing Concentrator (DPC) 600 (the 5 the scanning and printing devices. Each glyph element 

central data processing subsystem). The DataTreasury™ represents a binary 0 or 1 depending on whether it slopes 

System 100 architecture consists of three tiers. At the bottom downward to the left or the right respectively. Accordingly, 

tier, the DATs 200 retrieve data from the customer sites. At DataGlyph™ elements can represent character strings as 

the next tier, the DACs 400 poll the DATs 200 to receive data ASCII or EBCIDIC binary representations. Further, encryp- 

which accumulates in the DATs 200. At the top tier, the to tion methods, as known to persons of ordinary skill in the art 

DPCs 600 poll the DACs 400 to receive data which accu- encrypt the data represented by the DataGlyph™ Technol- 

mulates in the DACs 400. The DPCs 600 store the custom- ogy. 

er's data in a central location, generate informative reports The use of glyph technology in the DataTreasury™ 

from the data and transmit the informative reports to the System 100 improves the accuracy, cost and performance of 

customers at remote locations. 15 the system. Xerox DataGlyph™ Technology includes error 

In the preferred embodiment, the DataTreasury™ System correction codes which can be referenced to correct scan- 

100 complies with the Price Waterhouse SAS70 industry ning errors or to correct damage to the document caused by 

standard. Specifically, the DataTreasury™ System 100 ink spills or ordinary wear. DataGlyph™ Technology also 

meets the software development standard, the system leads to decreased system cost since the system will require 

deployment standard and the reliability standard specified by 20 less manual intervention for data entry and correction 

Price Waterhouse SAS70. By adhering to the Price Water- because of the improved accuracy associated with DataG- 

house SAS70 standard, the DataTreasury™ System 100 lyph elements. 

provides the security, availability and reliability required by since DataGlyph elements represent a large amount of 

mission critical financial applications of banks and stock information in a small amount of space, the DAT scanner 

brokerage companies. , 25 100 wilJ require a sma n amount of time to input a large 

As is known to persons of ordinary skill in the art, the amount of information. 

DataTreasury™ System 100 could also use other software The DAT card interface 212 and the DAT signature pad 

development standard, other system deployment standards 214 along with the internet and telephone access through the 

and other reliability standards as long as adherence to these DAT modem 204 enable the DataTreasury™ System 100 

alternative standards provides the security, availability and customer to initiate secure sale and banking transactions via 

reliability required by mission critical financial applications. the internet or telephone with the DAT 200 using a variety 

FIG. 2 shows a block diagram of the DAT 200 architec- of cards including debit cards, smart cards and credit cards, 

ture. DATs 200 are located at customer sites. The DataTrea- After selecting a purchase or a banking transaction through 

sury™ System 100 customers include merchants, consumers 35 a standard internet interface, the DataTreasury™ System 

and bankers. The DATs 200 act as the customer contact point 100 customer inserts or swipes the debit card, smart card or 

to the suite of services provided by the DataTreasury™ credit card into the DAT card interface 212, 

System 100. In the preferred embodiment, the DAT 200 is Th e DAT card interface 212 retrieves the identification 

custom designed around a general purpose thin client Net- information from the card for subsequent transmission to the 

work Computer (NC) which runs SUN Microsystem's ^ destination of the internet transaction. Further, the DAT 

JAVA/OS operating system. The custom designed DAI' 200 scanner 202 could capture a hand written signature from a 

comprises a DAT scanner 202, a DAT modem 204, DAT document or the DAT signature pad 214 could capture an 

digital storage 206, a DAT controller 210 (workstation), a electronic signature written on it with a special pen. 

DAT card interface 212, an optional DAT printer 208 and a Similarly, these security features allow a credit card recipi- 

signature pad 214. 45 e nt to activate the card with a DAT200 located at a merchant 

As is known to persons of ordinary skill in the art, the site. The security features would detect unauthorized use of 

DAT 200 could also be custom designed around a general debit cards, credit cards and smart cards resulting from their 

purpose network computer running other operating systems unlawful interception. Accordingly, the DataTreasury™ 

as long as the chosen operating system provides support for System's 100 security features offer a more secure alterna- 

multiprocessing, memory management and dynamic linking 50 live for internet and telephone transactions than the typical 

required by the DataTreasury™ System 100. methods which only require transmission of a card account 

The DAT scanner 202 scans a paper receipt and generates number and expiration date, 
a digital bitmap image representation called a Bitmap Image As is known to persons of ordinary skill in the art, the 
(BI) of the receipt. In the preferred embodiment, the DAT DATs 200 could also include additional devices for captur- 
scanner 202 has the ability to support a full range of image 55 ing other biometric data for additional security. These 
resolution values which are commonly measured in Dots Per devices include facial scans, fingerprints, voice prints, iris 
Inch (DPI). Next, the DAT scanner 202 has the ability to scans, retina scans and hand geometry, 
perform full duplex imaging. With full duplex imaging, a i n addition to initiating sale and banking transactions, the 
scanner simultaneous captures both the front and back of a DAT card interface 212 also reads sale and banking trans- 
paper document. The DAT scanner 202 can also support gray 60 actions initiated elsewhere from the memory of smart cards 
scale and full color imaging at any bit per pixel depth value. to enable subsequent storage and processing by the 
The DAT scanner 202 also supports the capture of hand- DataTreasury™ System. If a smart card is lost, stolen, 
written signatures for identity verification. damaged or deliberately altered by an unscrupulous holder 

In addition to scanning images and text, the DAT scanner after the DAT card interface 212 reads its transaction data, 

202 also scans DataGlyph™ elements, available from Xerox 65 the DataTreasury™ System 100 can reproduce the transac- 

Corporation. As is known to persons of ordinary skill in the tion data for the customer. Accordingly, the DAT card 

art, the Xerox DataGlyph™ Technology represents digital interface 212 provides support for independent verification 
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of the records maintained by consumers, merchants and If a BI is created, the DAT controller 210 executes a 

bankers to prevent the loss of data from the loss, theft, conventional image compression algorithm like the Tagged 

damage or deliberate alteration of the smart card. Image File Format (TIFF) program to compress the BI in 

The DAT card interface 212 also supports the initiation step 314. In step 316, the DAT controller 210 determines 

and retrieval of sale and banking transactions with the 5 whether the compression executed successfully. If the com- 

DataTreasury™ System anonymous smart cards. In contrast pression is successful, it produces a Compressed Bitmap 

to standard debit cards and credit cards, the DataTreasury™ Ima g e (CBI). If the compression is unsuccessful, the DAT 

System anonymous smart card does not identify the card's controller 210 notifies the operator of the trouble and 

holder by name. Instead, the DataTreasury™ System anony- prompts the operator for repair in step 370. 

mous smart card requires only an account number and a 10 If a CBI is created, the DAT controller 210 executes an 

password. Since DataTreasury™ System anonymous smart encryption algorithm which is well known to an artisan of 

card transactions can be identified without the customer's ordinary skill in the field to encrypt the CBI in step 318. 

name, a DataTreasury™ System 100 customer can purchase Encryption protects against unauthorized access during the 

a DataTreasury™ System anonymous smart card, add subsequent transmission of the data which will be discussed 

money to the card, make expenditures with the card and 15 below. In step 320, the DAT controller 210 determines 

monitor the card's account with the same degree of privacy whether the encryption operation executed successfully. If 

as cash acquisition, expenditure and management. the encryption is successful, it produces an Encrypted Com- 

The DAT scanner 202, the internet access, the signature pressed Bitmap Image (ECBI). If the encryption is 

pad 214 and other biometric data capture devices also unsuccessful, the DAT controller 210 notifies the operator of 

support the remote capture of survey information and pur- 20 the trouble and prompts the operator for repair in step 370. 

chase orders. For example, the DAT scanner 202 captures If an ECBI is created, the DAT controller 210 tags the 

surveys appearing on the back of checks at restaurants and ECBI with a time stamp which includes the scanning time, 

bars. Similarly, the DAT scanner 202 could capture purchase an identification number to identify the merchant originating 

orders from residences, enabling customers to make imme- the scan and any additional useful information in step 322. 

diate purchases from their home of goods promoted through 25 In step 324, the DAT controller 210 determines whether the 

the mail. Accordingly, home marketing merchant could tagging operation executed successfully. If the tagging is 

transmit sales in a more cost efficient and reliable manner by successful, it produces a Tagged Encrypted Compressed 

using the DAT scanner 202 instead of providing envelopes Bitmap Image (TECBI). If the tagging is unsuccessful, the 

with prepaid postage to residences. DAT controller 210 notifies the operator of the trouble and 

The DAT scanner 202 also captures receipts which are 30 prompts the operator for repair in step 370. 

subsequently needed for tax return preparation or tax audits. If a TECBI is created, the DAT controller 210 stores the 

Similarly, the DAT scanner 202 captures sales receipts from TECBI in the DAT digital storage 208 in step 326. In step 

merchants, providing an off-site secure, reliable repository 328, the DAT controller 210 determines whether the storing 

to guard against loss resulting from flooding, fire or other 35 operation executed successfully. If the storing operation is 

circumstances. This feature could also allow a merchant to successful, the DAT digital storage 208 will contain the 

automatically perform inventory in a reliable and cost- TECBI. If the storing operation is unsuccessful, the DAT 

effective manner. controller 210 notifies the operator of the trouble and 

The DAT controller 210 performs processing tasks and prompts the operator for repair in step 370. 

Input/Output (I/O) tasks which are typically performed by a 40 If the TECBI is properly stored in the DAT digital storage 

processor. The DAT controller 210 compresses, encrypts and 208, the DAT controller 210 determines whether all paper 

tags the BI to form a Tagged Encrypted Compressed Bitmap receipts have been scanned in step 330. If all paper receipts 

Image (TECBI). The DAT controller 210 also manages the have not been scanned, control returns to step 310 where the 

Input/Output (I/O). Specifically, the DAT controller 210 next paper receipt will be processed as discussed above. If 

manages devices like the DAT scanner 202, the DAT digital 45 all paper receipts have been scanned, the DAT controller 210 

storage 206, the optional DAT printer 208 and the DAT asks the operator to verify the number of scanned receipts in 

modem 204. step 334. If the number of scanned receipts as determined by 

The DAT digital storage 208 holds data such as the ^ DAr controller 210 does not equal the number of 

TECBI. The DAT modem 204 transmits data from the DAT scanned receipts as determined by the operator, the DAT 

200 to the appropriate DAC 400 as instructed by the DAT 50 controller 210 asks whether the operator desires to rescan all 

controller 210. Specifically, the DAT modem 204 transmits of the receipts in step 338. 

the TECBIs from the DAT digital storage 208 to the appro- If the operator chooses to rescan all of the receipts in step 

priate DAC 400. In the preferred embodiment, the DAT 338, the DAT controller 210 will delete all of the TECBIs 

modem 204 is a high speed modem with dial-up connectiv- associated with the batch from the DAT digital storage 208 

ity. The DAT digital storage 208 is sufficiently large to store 55 in step 342. After the operator prepares the batch of receipts 

the input data before transmission to a DAC 400. The DAT for rescan in step 346, control returns to step 310 where the 

digital storage 208 can be Random Access Memory (RAM) first receipt in the batch will be processed as discussed 

or a hard drive. above. 

FIG. 3a is a flow chart 300 describing the operation of the If the operator chooses not to rescan all of the receipts 

DAT in detail. In step 310, the DAT scanner 202 scans paper 60 from the batch in step 338, control returns to step 334 where 

receipts into the DAT 200 provided by an operator. In step the DAT controller 210 asks the operator to verify the 

312, the DAT controller 210 determines whether the opera- number of scanned receipts as discussed above, 

tion executed successfully. If the scanning is successful, the If the number of scanned receipts as determined by the 

DAT scanner 202 produces a Bitmap Image (BI). If the DAT controller 210 equals the number of scanned receipts as 

scanning is unsuccessful, the DAI' controller 210 notifies the 65 determined by the operator, the DAT controller 210 prints a 

operator of the trouble and prompts the operator for repair in batch ticket on the DAT printer 206 in step 350. The operator 

step 370. will attach this batch ticket to the batch of receipts which 
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have been scanned. This batch ticket shall contain relevant 
session information such as scan time, number of receipts 
and an identification number for the data operator. If pro- 
cessing difficulties occur for a batch of receipts after the 
image capture of flowchart 300, the batch ticket will enable 5 
them to be quickly located for rescanning with the DAI' 200. 

In step 354, the DAT controller 210 determines whether 
the scan session has completed. If the scan session has not 
completed, control returns to step 310 where the first receipt 
in the next batch of the scan session will be processed as 10 
discussed above. If the scan session has completed, the DAT 
controller 210 selectively prints a session report on the DAT 
printer 206 in step 358. The DAT controller 210 writes 
statistical information for the session to the DAT digital 
storage 208 in step 362. In step 366, the DAT controller 210 
terminates the session. 15 

FIG. 3b displays a sample paper receipt which is pro- 
cessed by the DAT 200 as described by the flowchart in FIG. 
3a. The sample paper receipt involves a credit card trans- 
action which has four participants: 

A. The ISSUER: is an entity such as a bank or corporate 20 
financial institution such as GE Capital, GM or AT&T 
which provides the credit behind the credit card and 
issues the card to the consumer. 

B. The PROCESSOR: executes the processing of an 
inbound credit card transaction by performing basic 25 
transaction validation that includes checking with the 
ISSUER database to ensure that the credit card has 
sufficient credit to allow approval of the transaction. 

C. The ACOUIRER: specializes in the marketing, instal- 
lation and support of Point Of Sale (POS) credit card 30 
terminals. The acquirer, like the DAC 400 in the 
DataTreasury™ System 100 acts as an electronic col- 
lection point for the initial credit card transaction as the 
card is inserted into the POS terminal. After 
acquisition, the acquirer passes the transaction to the 35 
PROCESSOR. 

D. The MERCHANT: inserts a credit card into a POS 
terminal and enters the amount of the transaction to 
initiate the credit card transaction. 

In the preferred embodiment, the DAT 200 reads the 4Q 
following information from the sample paper receipt shown 
in FIG. 3b and stores the information in the format described 
below. 

CUSTOMER_ID 370: This field is a 7 position HEX 
numeric value. This field uniquely identifies the cus- 4S 
tomer using the terminal. In this sample, this field 
would identify the credit card merchant. 

TERMINALJD 372: This field is a 6 position decimal 
numeric value. This field uniquely identifies the credit 
card terminal which is used to print the credit card 50 
receipt. 

TRANSACnON_DATE 374: This field contains the 
date and time of the credit card transaction. 

TRANS ACTION_ LI NE_ITEM 376: This field is a vari- 
able length character string. The first three positions 55 
represent a right justified numeric field with leading 
zeros indicating the full length of this field. This field 
contains all data pertaining to the purchased item 
including the item's price. The DAT 200 will store a 
TRANSACnON_LINE„ITEM field for each trans- 6 o 
action line item on the receipt. This field is optional 
since not all credit card transactions will have line 
items. 

TRANSACTION__SUBTOTAL 378: This field is a 
double precision floating point number. This field indi- 65 
cates the subtotal of the TRANSACTION_JLINE_ 
ITEMs. 



TRANSACTION_SALES__TAX 380: This field is a 
double precision floating point number. This field con- 
tains the sales tax of the TRANSACTION^ 
SUBTOTAL. 

TRANSACTION_AMOUNT 382: This field is a double 
precision floating point number. This field is the sum of 
the TRANSACTION_SUBTOTAL and 
TRANSACTION„SALES_TAX. 

CREDIT_CARD_ACCT_NUM 384: This field is a 12 
position decimal value. This field identifies the credit 
card which was used to execute this transaction. 

CREDIT_CARD„EXP_DATE 386: This field identifies 
the expiration date of the credit card. 

TRANSACTION„APPROVAL„CODE 388: This field 
is a 6 position numeric value. This field indicates the 
approval code that was given for the particular trans- 
action. 

The DAT 200 also stores additional items which are not 
pictured in FIG. 36 as described below: 

ISSUER_ID: This field is a 7 position decimal numeric 
value. This field identifies the credit card issuer. 

ACQUIRER_ID: This field is a 7 position decimal 
numeric value. This field identifies the acquirer. 

PROCESSOR_ID: This field is a 7 position decimal 
numeric value. This field identifies the processor. 

TR ANS A CTI O N_LI NE__ITEM„C NT: This field is a 3 
position decimal numeric value. This field identifies the 
number of transaction line items on the receipt. A value 
of ZERO indicates the absence of any transaction line 
items on the receipt. 

TRANSACTION_GRATUITY: This field is a double 
precision floating number. This field is optional 
because it will only appear on restaurant or bar receipts. 

FINAL_TRANS ACTION _AMOUNT: This field is a 
double precision floating number, litis field is optional 
because it will only appear on restaurant and bar 
receipts. The field is the sum of the TRANS ACTION_ 
AMOUNT and TRANSACTION_GRATUITY. 

The tag prepended to the ECBI in step 322 of the 
flowchart of FIG. 3a identifies the time and place of the 
document's origination. Specifically, the tag consists of the 
following fields: 

DAT_TERMINAL_ID: This field is a 7 position hexa- 
decimal numeric value. This field uniquely identifies 
the DAT 200 which is used by the customer. 

DAT_SESSION_DATE: This field identifies the date 
and time of the DAT 200 session which generated the 
image of the document. 

DAT__USER_ID: This field is a 4 position decimal 
numeric value. This field identifies the individual 
within the CUSTOMER'S organization who initiated 
the DAT 200 session. 

DATA^GLYPH_RESULT: This field is a variable length 
character string. The first four positions hold a right 
justified numeric position with leading zero which 
indicate the length of the field. The fifth position 
indicates the DataGlyph™ element status. A value of 0 
indicates that the data glyph was NOT PRESENT on 
the receipt. A value of 1 indicates that the data glyph 
WAS PRESENT and contained no errors. A value of 2 
indicates that the data glyph WAS PRESENr and had 
nominal errors. If the fifth position of this field has a 
value of 2, the remaining portion of the string identifies 
the erroneous field numbers. As subsequently 
described, the DPC 600 will reference this portion of 
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the field to capture the erroneous data from the receipt of different database models which are available from other 
with alternate methods. A value of 3 indicates that the vendors including the entity relationship model as long as 
data glyph WAS PRESENT WITH SEVERE the selected database meets the storage and access efficiency 
ERRORS. In other words, a value of 3 indicates the requirements of the system. See, e.g., Chapter 2 of Database 
DataGlyph™ element was badly damaged and unread- 5 System Concepts by Korth and Silberschatz. 
able - The DAC 400 architecture uses a WEB based paradigm 
The receipt shown in FIG. 3b can also contain a signature usi an enhanced Domain Name Services (DNS), the 
whichcanbecapturedbythepATsc a nner202.Adatagl y ph Microsoft Component Object Model (DCOM), and Win- 
could identify the location of the signature on the receipt. dows m Applicalion p m Interface s (APIs) to facilitate 
As is known to persons of ordinary skill in the art, the „ . . , , ? , \u 
. Ti tm o . ,n A t . i i io communication and load balancing among the servers corn- 
Data 1 reasury rM System 10U can also process receipts with A , T^AS> At*** A * 1 . C 

alternate formats as long as the receipt contains the appro- P n f m S ^ u TT * °I 

priate identification information such as the transaction ordmary skill m the art, DNS, which is also known as Bind 

amount, the customer, the DAT 200, the transaction date, the statically translates name requests to Internet Protocol 4 

transaction tax, the credit card number, the credit card ( 1P4 ) addresses. In the DAC 400 architecture, an enhanced 

expiration date, etc. 15 DNS dynamically assigns 1P4 addresses to balance the load 

The DataTreasury™ System 100 partitions the paper among the servers comprising the DAC server 402. 

receipt into image snippets as illustrated by the sample on In the preferred embodiment, the enhanced DNS is 

FIG. 3b. Partitioning facilitates an improvement in the designed and implemented using objects from Microsoft 

process to correct errors from the scanning operation. If an DCOM. Using the DCOM objects, the enhanced DNS 

error occurred during scanning, the DataTreasury™ System 20 acquires real-time server load performance statistics on each 

100 corrects the error using manual entry. With partitioning, server comprising the DAC server 402 from the Windows 

the DataTreasury™ System 100 focuses the correction effort NT API at set intervals. Based on these load performance 

on only the image snippet having the error instead of statistics, the enhanced DNS adjusts the mapping of name 

correcting the entire document. The subsequently discussed requests to IP4 addresses to direct data toward the servers 

schema of the DataTreasury™ System 100 database 25 which are more lightly loaded. 

describes the implementation of the partitioning concept in A large bank of modems 404 polls the DATs 200 at the 

detail. customer sites within the DACs 400 region. In the preferred 

The DACs 400 form the backbone of the tiered architec- embodiment, the bank of modems 404, available as CISCO 

hire shown in FIG. 1 and FIG. 4. As shown in FIG. 1, each AS5200, is an aggregate 48 modem device with Local Area 

DAC 400 supports a region containing a group of DATs 200. 30 Network (LAN) 406 connectivity which permits the DAC 

Each DAC 400 polls the DATs 200 in its region and receives servers 402 to dial the DATs 200 without requiring 48 

TECBIs which have accumulated in the DATs 200. The separate modems and serial connections. 

DACs 400 are located at key central sites of maximum The DAC servers 402 and the bank of modems 404 are 

merchant density. connected on a LAN 406. In the preferred embodiment, the 

In the preferred embodiment, the DAC server 402 com- 35 LAN uses a switched 100Base T/lOBaseT communication 

prises stand-alone Digital Equipment Corporation (DEC) hardware layer protocol. As is known to persons of ordinary 

SMP Alpha 4100 2/566 servers which are connected on a skill in the art, the lOOBaseT/lOBaseT protocol is based on 

common network running Windows NT. The DEC Alpha the Ethernet model. Further, the numbers 100 and 10 refer to 

servers manage the collection and intermediate storage of the communication link speed in megabits per second. In the 

images and data which are received from the DATs 200. 40 preferred embodiment, the CISCO Catalyst 2900 Network 

As is known to persons of ordinary skill in the art, the Switch supports the LAN 406 connectivity between the 

DataTreasury™ System 100 could use any one of a number devices connected to the LAN 406 including the DAC 

of different servers that are available from other computer servers 402 and the bank of modems 404. 

vendors as long as the server meets the capacity, perfor- As is known to persons of ordinary skill in the art, 

mance and reliability requirements of the system. 45 alternate LAN architectures could be used to facilitate 

In the preferred embodiment, the DAC server 402 also communication among the devices of the LAN 406. For 
comprises EMC 3300 SYMMETRIX CUBE Disk Storage example, the LAN 406 could use a hub architecture with a 
Systems, which store the images and data collected and round robin allocation algorithm, a time division multiplex- 
managed by the DEC Alpha servers. The DAC 400 archi- ing algorithm or a statistical multiplexing algorithm, 
tecture also uses a SYMMETRIX Remote Data Facility 50 A Wide Area Network (WAN) router 408 connects the 
(SRDF), available from EMC, to enable multiple, physically LAN 406 to the WAN to facilitate communication between 
separate data centers housing EMC Storage Systems to the DACs 400 and the DPCs 600. In the preferred 
maintain redundant backups of each other across a Wide embodiment, the WAN router 408 is a CISCO 4700 WAN 
Area Network (WAN). Since SRDF performs the backup Router. The WAN router 408 uses frame relay connectivity 
operations in the background, it does not affect the opera- 55 to connect the DAC LAN 406 to the WAN. As is known to 
tional performance of the DataTreasury™ System 100. The persons of ordinary skill in the art, alternate devices, such as 
DAC server 402 also has secondary memory 410. In the the NORTEL Magellen Passport "50" Telecommunication 
preferred embodiment, the secondary memory 410 is a small Switch, could be used to facilitate communication between 
scale DLT jukebox. the DACs 400 and the DPCs 600 as long as the selected 

The DAC Alpha servers of the DAC server 402 insert 60 router meets the performance and quality communication 

images and data received from the DATs 200 into a database requirements of the system. 

which is stored on the disk storage systems using a data As is known to persons of ordinary skill in the art, frame 

manipulation language as is well known to persons of relay is an interface protocol for statistically multiplexed 

ordinary skill in the art. In the preferred embodiment, the packet-switched data communications in which variable - 

database is a relational database available from Oracle. 65 sized packets (frames) are used that completely enclose the 

As is well known to persons of ordinary skill in the art, the user packets which they transport. In contrast to dedicated 

DataTreasury™ System 100 could use any one of a number point to point links that guarantee a specific data rate, frame 



6,032,137 

13 14 

relay communication provides bandwidth on-demand with a condition in the session summary report and will report the 

guaranteed minimum data rate. Frame relay communication error to the DPC 600 in step 522. 

also allows occasional short high data rate bursts according If the TECBI packet header matched the TECBI packet in 

to network availability. step 518, the DAC 400 will set the status of the TECBI 
Each frame encloses one user packet and adds addressing 5 P ac ket to indicate that it is ready for transmission to the DPC 

and verification information. Frame relay data communica- 600 in ste P 520 ' llic DAC 400 wil1 als0 transmit the status 

lion typically has transmission rates between 56 kilobytes to the DAT 200 t0 indicate successful completion of the 

per second (kb/s) and 1.544 megabytes per second (Mb/s). P°L lin g an , d transmission session in step 520. Next, the DAC 

Frames may vary in length up to a design limit of approxi- w ! 1 d /* rm V£ ^ AA ther have b ^<J V* n ?™"* d 

matclv 1 kilobyte 10 in lts re 8 10n in ste P 524 ' If a11 DATs 

t-u -r i ^ - ^ -i ^ii • ■ *• * i 200 in the DACs 400 region have transmitted TECBIs to 

Ine lelco Carrier Cloud 412 is a communication network nA/ > Aaii tU ^ Ar , A nn n -i at- nnn * * 

.. , r . . r rtxn , the DAC 400, the DAC 400 will compile a DAT 200 status 

which receives the frames destined for the DPC 600 sent by m 528 beforc tcrminati ^ ^n. 

the WAN router 408 from the DACs 400. As is known to , f onc or morc DArs 200 ^ mc DACs 400 region havc 

persons of ordinary skill in the art, carriers provide com- not transmitted TECBIs to thc DAC 400, the DAC 400 will 
mumcation services at local central offices. These central 15 get the address of the next DAT 200 in thc region in step 526. 
offices contain networking facilities and equipment to inter- Next, control returns to step 504 where the next DAT 200 in 
connect telephone and data communications to other central the DACs 400 region will be polled as previously dis- 
offices within its own network and within networks of other cussed. 

carriers. In the preferred embodiment, the DAC server 402 ini- 

Since carriers share the component links of the intercon- 20 tiates the polling and data transmission at optimum toll rate 
nection network, data communication must be dynamically times to decrease the cost of data transmission. In addition 
assigned to links in the network according to availability. to the raid drives and redundant servers, the DAC 400 will 
Because of the dynamic nature of the data routing, the also have dual tape backup units which will periodically 
interconnection network is referred to as a carrier cloud of backup the entire data set. If there is a catastrophic failure of 
communication bandwidth. 25 the DAC 400, the tapes can be retrieved and sent directly to 

All the DAC 400 equipment is on fully redundant on-line thc DPC 600 for processing. As the DAT 200 polling and 
UPS power supplies to insure maximum power availability. data transmission progresses, the DAC 400 will periodically 
Further, to minimize the time for trouble detection, trouble update the DPC 600 with its status. If there is a catastrophic 
analysis and repair, all the DAC 400 equipment incorporates failure with the DAC 400, the DPC 600 would know how 
trouble detection and remote reporting/diagnostics as is 30 much polling and backup has been done by the failing DAC 
known to an artisan of ordinary skill in the art. 400. Accordingly, the DPC 600 can easily assign another 

FIG. 5 is a flow chart 500 describing the polling of the DAC 400 to complete the polling and data transmission for 
DATs 200 by a DAC 400 and the transmission of the the DATs 200 in the failed DACs 400 region. 
TECBIs from the DATs 200 to the DAC 400. In step 502, the FIG. 6 is a block diagram of the DPC 600 architecture. 
DAC server 402 reads the address of thc first DAT 200 in its 35 The DPC 600 accumulates, processes and stores images for 
region for polling. In step 504, a modem in the modem bank later retrieval by DataTreasury™ System retrieval custom- 
404 dials the first DAT 200. The DAC 400 determines crs who have authorization to access relevant information, 
whether the call to the DAT 200 was successful in step 506, DataTreasury™ System retrieval customers include credit 
If the call to the first DAT 200 was unsuccessful, the DAC card merchants, credit card companies, credit information 
400 will record the error condition in the session summary 40 companies and consumers. As shown in FIG. 6 and FIG. 1, 
report and will report the error to the DPC 600 in step 522. the DPC 600 polls the DACs 400 and receives TECBIs 

If the call to the first DAT 200 was successful, the DAC which have accumulated in the DACs 400. 
400 will verify that the DAT 200 is ready to transmit in step In the preferred embodiment, the DPC server 602 com- 
508. If the DAT 200 is not ready to transmit, the DAC 400 prises stand-alone Digital Equipment Corporation (DEC) 
will record the error condition in the session summary report 45 SMP Alpha 4100 4/566 servers which are connected on a 
and will report the error to thc DPC 600 in step 522. common network running Windows NT. The DEC Alpha 

If the DAT 200 is ready to transmit in step 508, the DAT servers manage the collection and intermediate storage of 
200 will transmit a TECBI packet header to the DAC 400 in images and data which are received from the DACs 400. 
step 510. The DAC 400 will determine whether the trans- In the preferred embodiment, the DPC server 602 also 
mission of the TECBI packet header was successful in step 50 comprises EMC 3700 SYMMETRIX CUBE Disk Storage 
512. If the transmission of the TECBI packet header was Systems, which store the images and data collected and 
unsuccessful, the DAC 400 will record the error condition in managed by the DEC Alpha servers. Like the DAC 400 
the session summary report and will report the error to the architecture, thc DPC 600 architecture uses a SYMMETRIX 
DPC 600 in step 522. Remote Data Facility (SRDF), available from EMC, to 

If the transmission of thc TECBI packet header was 55 enable multiple, physically separate data centers housing 
successful in step 512, the DAI' 200 will transmit a TECBI EMC Storage Systems to maintain redundant backups of 
packet to the DAC 400 in step 514. The DAC 400 will each other across a Wide Area Network (WAN), 
determine whether the transmission of the TECBI packet Like the DAC 400 architecture, the DPC 600 architecture 
was successful in step 516. If the transmission of the TECBI uses a WEB based paradigm using an enhanced Domain 
packet header was unsuccessful, the DAC 400 will record 60 Name Services (DNS), the Microsoft Component Object 
the error condition in the session summary report and will Model (DCOM), and Windows NT Application Program 
report the error to the DPC 600 in step 522. Interfaces (APIs) to facilitate communication and load bal- 

If the transmission of the TECBI packet was successful in ancing among the servers comprising the DPC server 602 as 
step 516, the DAC 400, in step 518, will compare the TECBI described above in the discussion of the DAC 400 architec- 
packet header transmitted in step 510 to the TECBI packet 65 ture. 

transmitted in step 514. If the TECBI packet header does not The workstation 604 performs operation control and 
match the TECBI packet, the DAC 400 will record the error system monitoring and management of the DPC 600 net- 
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work. In the preferred embodiment, the workstation 604, DPC server 602 and the network workstation 604. In the 
available from Compaq, is an Intel platform workstation preferred embodiment, the DPC LAN 606 uses a switched 
running Microsoft Windows NT 4.x. The workstation 604 1 00BascT/l OBaseT communication hardware layer protocol 
should be able to run Microsoft Windows NT 5.x when it like the DAC LAN 406 discussed earlier. In the preferred 
becomes available. The workstation 604 executes CA 5 embodiment, the DPC LAN 406 is a high speed OC2 
Unicenter TNG software to perform network system moni- network topology backbone supporting TCP/IP. The CISCO 
tormg and management The workstation 604 executes Catalyst 5500 NelW ork Switch supports the DPC LAN 606 
TECB°I ^ l ° Pr ° CeSS connectivity among the devices connected to the LAN 606. 
m. s " , /Ai . <. . t .„ As is known to persons of ordinary skill in the art, 
Iiie workstation 604 also performs identification verm- ft 4 T AM U T # . « . c .,.„ . 
. . . V, . . . j i * i io alternate LAN architectures could be used to facilitate 
cation by comparing signature data retrieved remotely by the . 4 . , . . lL r AVT , n , r 
DATs 200 with signature data stored at the DPC 600. In the communication am ong the devices of the LAN 406. For 
preferred embodiment, signature verification software, example the LAN 406 could use a hub architecture with a 
available from Communications Intelligence Corporation of round robm allocation algorithm, a time division multiplex- 
Redwood Shores, Calif, executing on the workstation 604 m & algorithm or a statistical multiplexing algorithm, 
performs the identification verification. As is known to 15 A Wlde Network (WAN) router 612 connects the 
persons of ordinary skill in the art, the workstation 604 could DPC LAN 606 t0 the WAN l ° facilitate communication 
execute other software to perform identification verification between the DACs 400 and the DPCs 600. In the preferred 
by comparing biometric data including facial scans, embodiment, the WAN router 612 is a CISCO 7507 WAN 
fingerprints, retina scans, iris scans and hand geometry. Router. The WAN router 612 uses frame relay connectivity 
Thus, the DPC 600 could verify the identity of a person who 20 to connect the DPC LAN 612 to the WAN. As is known to 
is making a purchase with a credit card by comparing the persons of ordinary skill in the art, alternate devices, such as 
biometric data captured remotely with the biometric data the NORTEL Magellen Passport "50" Telecommunication 
stored at the DPC 600. Switch, could be used to facilitate communication between 
As is known to persons of ordinary skill in the art, the the DACs 400 and the DPCs 600 as long as the selected 
DataTreasury™ System 100 could use workstations with 25 router meets the performance and quality communication 
central processing units from other integrated circuit ven- requirements of the system. 

dors as long as the chosen workstation has the ability to The DPC 600 has a three tier storage architecture to 

perform standard operations such as fetching instructions, support the massive storage requirement on the DataTrea- 

fetching data, executing the fetched instructions with the sury™ System 100. In the preferred embodiment, the stor- 

fetched data and storing results. Similarly, the DataTrea- 30 age architecture consists of Fiber Channel RAID technology 

sury™ System 100 could use alternate windows operating based EMC Symmetrix Enterprise Storage Systems where 

systems and network monitoring software as long as the individual cabinets support over 1 Terabyte of storage. After 

selected software can monitor the status of the workstations TECBI images have been processed and have been on-line 

and links in the network and display the determined status to for 30 days, they will be moved to DVD based jukebox 

the operator. The Remote Data Entry Gateway 614 and the 35 systems. After the TECBI images have been on-line for 90 

Remote Offsite Data Entry Facilities 616 correct errors days, they will be moved to Write Once Read Many 

which occurred during data capture by the DAT 200. Since (WORM) based jukebox systems 608 for longer term stor- 

the DataTreasury™ System 100 partitions the document as age of up to 3 years in accordance with customer require- 

described in the discussion of the sample receipt of FIG. 3fc, ments. 

the operator at the Remote Data Entry Gateway 614 or the 40 In an alternate embodiment, the DPC 600 is intended to 

Remote Offsite Date Entry Facilities 616 only needs to also configure a High Density Read Only Memory (HD- 

correct the portion of the document or image snippet which ROM) when it becomes available from NORSAM 

contained the error. Technologies, Los Alamos, N. Mex., into optical storage 

Partitioning improves system performance, decreases sys- jukebox systems 610, such as that which is available from 

tern cost and improves system quality. With partitioning, the 45 Hewlett Packard, to replace the DVD components for 

DPC Server 602 only sends the portion of the document increased storage capacity. The HD-ROM conforms to 

containing the error to the Remote Data Entry Gateway 614 CD-ROM form factor metallic WORM disc. The HD-ROM 

or the Remote Offsite Data Entry Facilities 616. Since the currently has a very large storage capacity of over 320 giga 

operator at these data entry locations only sees the portion of bytes (320 GB) on a single platter and has an anticipated 

the document which contained the error, she can quickly 50 capacity of several terabytes (TB) on a single platter. The 

recognize and correct the error. Without partitioning, the DPC 600 uses IBM and Philips technology to read from the 

operator would have to search for the error in the entire HD-ROM and to write to the HD-ROM. 

document. With this inefficient process, the operator would The DPC Alpha servers of the DPC server 602 insert 

need more time and would be more likely to make a mistake images and data received from the DACs 400 into a single 

by missing the error or making a modification in the wrong 55 database which is stored on the Digital Storage Works 

location. Accordingly, partitioning improves system perfor- Systems using a data manipulation language as is well 

mance and quality by increasing the speed and accuracy of known to persons of ordinary skill in the art. In the preferred 

the error correction process. embodiment, the database is the V8.0 Oracle relational 

Similarly, partitioning decreases the traffic on the DPC database which was designed to support both data and image 

LAN 606 and the Telco Carrier Cloud 412 because the DPC 60 storage within a single repository. 

Server 602 only sends the image snippet containing the error As known to persons of ordinary skill in the art, a 

to the Remote Offsite Data Entry Facility 616 or the Remote relational database consists of a collection of tables which 

Data Entry Gateway 614. Accordingly, partitioning have a unique name. See, e.g., Chapter Three of Database 

decreases system cost by reducing the bandwidth require- System Concepts by Korth and Silberschatz. A database 

ment on the interconnection networks. 65 schema is the logical design of the database. Each table in 

A DPC LAN 606 facilitates communication among the a relational database has attributes. A row in a table repre- 

devices which are connected to the LAN 606 including the sents a relationship among a set of values for the attributes 
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in the table. Each table has one or more superkeys. A 
superkey is a set of one or more attributes which uniquely 
identify a row in the table. A candidate key is a superkey for 
which no proper subset is also a superkey. A primary key is 
a candidate key selected by the database designer as the 5 
means to identify a row in a table. 

As is well known to persons of ordinary skill in the art, the 
DataTreasury ™ System 100 could use other database mod- 
els available from other vendors including the entity rela- 10 
tionship model as long as the selected database meets the 
storage and access efficiency requirements of the system. 
See, e.g., Chapter 2 of Database System Concepts by Korth 
and Silberschatz. 

An exemplary DPC 600 basic schema consists of the 15 
tables listed below. Since the names of the attributes are 
descriptive, they adequately define the attributes' contents. 
The primary keys in each table arc identified with two 
asterisks (**). Numeric attributes which arc unique for a 
particular value of a primary key are denoted with the suffix, 
"NO". Numeric attributes which are unique within the entire 
relational database are denoted with the suffix, "NUM". 



CUSTOMER: This tabic describes the 
DataTreasury ™ System customer. 
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-continued 



CUSTOM ER_SITE_DAT: This table describes 
the DAT sile(s) of the DataTreasury ™ 
System customer. 
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A. • "D AT_TER M IN AL__I D 

B. *-DAT_SITE_NO 

C. "CUST_ID 

D. INSTALLED ATE 

E. LAST_SERVICE_DATE 

F. CREATE_DATE 

G. COMMENTS 
DATA_SPEC: This table provides data specif- 
ications for document partitioning and extraction. 

A. *-DATA_SPEOJD 

B. ~CUST„ID 

C. DESCR 

D. RECORD_LAYOUT_RULES 

E. CREATE_DATE 

F. COMMENTS 
DATA_SPEC_FIELD: This table provides 
field data specifications for document partitioning 
and extraction. 



A. 
B. 
C. 
D. 
E. 
F. 
G. 
H. 

r. 



*"DATA_SPEC_NO 

'■DATA_SPEC_ID 

FIELD__NAME 

DESCR 

DATA_TYPE 

VALUE_MAX 

VALUE_MIN 

START_POS 

END_POS 



A. 


"CUSTOMER_ID 






J. 


FIELD_LENGTH 


B. 


COMPANY_NAME 






K. 


RULES 


C. 


CONTACT 






L. 


C REATE„ DATE 


D. 


CONTACT_Tn*LE 


30 




M. 


COMMENTS 


E. 


ADDR1 




VII. 


TEMPL. 


„DOC: This table specifies the parti- 


F. 


ADDR2 






tioning of a predefined document. 


G. 


CITY 






A. 


**TEMPL_DOC_NUM 


H. 


STATE_CODE 






B. 


DATA_SPEC_ID 


I. 


ZIP_CODE 






C. 


DESCR 


J. 


COUNTRY_CODE 
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D. 


RULES 


K. 


VOX_PHONE 




E. 


CREATE_DATE 


L. 


FAX_PHONE 






F. 


COMMENTS 


M. 


CREATE_DATE 




VIII. 


TEMPL_ 


_FORM: This table defines the location 



CUSTOM ER_MAIL_TO: This table 
describes the mailing address of the 
DataTreasury ™ System customer. 



of forms on a predefined document. 



A. 
B. 
C. 
D. 
E. 
F. 
G. 
H. 
I. 
J. 
K. 



**MAIL_TO_NO 

**CUST_JD 

CUSTOMER_NAME 

CONTACT 

CO NTACT_TI LE 

ADDR1 

ADDR2 

CITY 

STATE _CODE 

ZIP„CODE 

COUNTRY_CODE 
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A. 


* -templ_form_.no 


B. 


• *TEMPL_DOC_NUM 


C. 


SIDES_PER_FORM 


D. 


MASTER_IMAGE_SrDE_A 


E. 


MASTER_IMAGE„SIDE_B 


F. 


DISPI.AY_ROTATTON _a 


a 


DISPLAY_ROTATTON_J3 


H. 


DESCR 




RULES 


j. 


CREATE_DATE 



IX. 



TEMPL_PANEL: This table specifies the lo- 
cation of panels within the forms of a 
predefined document. 



IIL 



L. VOX_PHONE 




A. 


* "TEMPL_PANEL__NO 


M. FAX_PHONE 


50 


B. 


* *TEMPL_SIDE_NO 


N. CREATE_DATE 




C. 


* TEMPL_FORM_NO 


O. COMMENTS 




D. 


* ^EMPL_DOC_NUM 


CUSTOM E R__DAT_SrrE : This table describes 




E. 


DISPLAY_ROTATION 


the DAI" location of the DataTreasury ™ 




F. 


PANEL_UL_X 


System customer. 




G. 


PANEL_UL_Y 


A. * * DAT_SrrE_NO 


55 


H. 


PANEL_LR _X 


B. *'CUST_ID 




PANEL_LR_Y 


C CUSTOM ER_NAME 




J. 


DESCR 


D. CONTACT 




K. 


RULES 


E. CONTACT_TILE 




L. 


C REATE„ D ATE 



F. 
G. 
H. 

J. 

K. 

L. 

M. 

N. 

O. 



ADDR3 
ADDR2 
CITY 

STATE_CODE 

ZIP_CODE 

COUNTRY_CODE 

VOX_PHONE 

FAX_PHONE 

CR E ATE _ DATE 

COMMENTS 
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TEMPL_FIELD: This table defines the loc- 
ation of fields within the panels of a form of a 
predefined document. 
A. * "TE M PL_ FI ELD_NO 

b. * -templ__panel_.no 

C ' -templ_side_no 

D. • templ_form_no 

E. *-templ„doc_num 
f. display_rotation 

G. FLD_UL_X 
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-continued 





H. 


FLD_UL_Y 






FLD_LR _X 




J. 


FLD_LR_Y 




K. 


DESCR 






RULES 




M. 


CREATE_DATE 


XL 


DAT_B ATCH : This table defines batches of 




documents which were processed during a 




DAT session. 




A. 


* *DAT_BATCH_NO 




B. 


**DAT_SESSION_NO 




C 


**DAT_SESSION_DATE 




D. 


* *DAT_TERMINAL„ID 




E. 


DAT_UNIT_CNT 




F. 


C RE ATE _ DATE 


XII. 


DAT_UNIT: This table defines the unit 




in t 


\ batch of documents which were processed 




in : 


i DAT session. 




A. 


**DAT_UNIT_NUM 




B. 


* *DAT_BATCH_NO 




C. 


" *DAT_SESSION_NO 




D. 


* * DAT_SESSION_DATt: 




E. 


* •DAT_TERMINAL_ID 




K 


FORM_CNT 




G. 


DOC_CNT 




H. 


CREATE_DATE 


XIII. 


DAT_DOC: This table defines documents 




in 1 


:he unit of documents which were 




processed in a DAT session. 




A. 


**DAT_DOC_NO 




B. 


* *DAT_UNTT___NUM 




C. 


DOC_RECORD_DATA 




D. 


CREATE_DATE 



The DATA__SPEC, DATA_SPEC_FIELD, TEMPL_ 
DOC, TEMPL_FORM, TEM PL_PAN EL and TEMPL_ 
FIELX) tables implement the document partitioning algo- 
rithm mentioned above in the discussion of the sample 
receipt of FIG. 3b. The cross product of the DAEA^SPEC 
and DATA_SPEC_FIELD tables partition arbitrary docu- 
ments while the cross product of the TEMPL_DOC, 
TEMPL_FORM, TEMPL„PANEL and TEMPL_FIELD 
tables partition predefined documents of the DataTreasury™ 
System 100. The TEMPL_FORM defines the location of 
forms on a predefined document. The TEMPL_PANEL 
defines the location of panels within the forms of a pre- 
defined document. Finally, the TEMPL_FIELD table 
defines the location of fields within the panels of a form of 
a predefined document. 

The DPC 600 performs data mining and report generation 
for a wide variety of applications by returning information 
from the data base. For example, the DPC 600 generates 
market trend analysis reports and inventory reports for 
merchants by analyzing the data from receipts captured by 
the DAT 200. The DPC 600 also can provide important tax 
information to the taxpayer in the form of a report or to 
software applications like tax preparation software by 
retrieving tax information from the database which origi- 
nally resided on receipts, documents and electronic trans- 
actions captured by the DAT 200. Similarly, the DPC 600 
can also provide tax information for particular periods of 
time for a tax audit. 

FIG. 7 is a flow chart 700 describing the polling of the 
DACs 300 by a DPC 600 and the transmission of the 
TECBIs from the DACs 300 to the DPC 600. In step 702, the 
DPC 600 reads the address of the first DAC 300 in its region 
for polling. 

In step 704, the DPC 600 connects with a DAC 300 for 
transmission. The DPC 600 determines whether the connec- 
tion to the DAC 300 was successful in step 706. If the call 
to the DAC 300 was unsuccessful, the DPC 600 will record 
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the error condition in the session summary report and will 
report the error to the DPC 600 manager in step 722. 

If the connection to the DAC 300 was successful, the DPC 
600 will verify that the DAC 300 is ready to transmit in step 

5 708. If the DAC 300 is not ready to transmit, the DPC 600 
will record the error condition in the session summary report 
and will report the error to the DPC 600 manager in step 722. 

If the DAC 300 is ready to transmit in step 708, the DAC 
300 will transmit a TECBI packet header to the DPC 600 in 

10 step 710. The DPC 600 will determine whether the trans- 
mission of the TECBI packet header was successful in step 
712. If the transmission of the TECBI packet header was 
unsuccessful, the DPC 600 will record the error condition in 
the session summary report and will report the error to the 

15 DPC 600 manager in step 722. 

If the transmission of the TECBI packet header was 
successful in step 712, the DAC 300 will transmit a TECBI 
packet to the DPC 600 in step 714. The DPC 600 will 
determine whether the transmission of the TECBI packet 

20 was successful in step 716. If the transmission of the TECBI 
packet header was unsuccessful, the DPC 600 will record the 
error condition in the session summary report and will report 
the error to the DPC 600 manager in step 722. 

If the transmission of the TECBI packet was successful in 

25 step 716, the DPC 600, in step 718, will compare the TECBI 
packet header traasmitted in step 710 to the TECBI packet 
transmitted in step 714. If the TECBI packet header does not 
match the TECBI packet, the DPC 600 will record the error 
condition in the session summary report and will report the 

30 error to the DPC 600 manager in step 722. 

If the TECBI packet header matched the TECBI packet in 
step 718, the DPC 600 will set the status of the TECBI 
packet to indicate that it was received at the DPC 600 in step 
720. The DPC 600 will also transmit the status to the DAC 

35 300 to indicate successful completion of the polling and 
transmission session in step 720. Next, the DPC 600 will 
determine whether TECBIs have been transmitted from all 
of the DACs 300 in its region in step 724. If all DACs 300 
in the DPC's 600 region have transmitted TECBIs to the 

40 DPC 600, the DPC 600 will compile a DAC 300 status 
report in step 728 before terminating the session. 

If one or more DACs 300 in the DPC's 600 region have 
not transmitted TECBIs to the DPC 600, the DPC 600 will 
get the address of the next DAC 300 in the region in step 

45 7 26. Next, control returns to step 704 where the next DAC 
300 in the DPC's 600 region will be polled as previously 
discussed. 

FIG. 8 is a flow chart 800 describing the data processing 
performed by the DPC 600. In step 802, the DPC 600 fetches 

50 the first TECBI packet. Next, the DPC 600 extracts the first 
TECBI from the TECBI packet in step 804. In step 806, the 
DPC 600 inserts the TECBI into the database. In step 808, 
the DPC 600 extracts the tag header which includes the 
customer identifier, the encryption keys and the template 

55 identifier from the TECBI to obtain the ECBI. 

In step 810, the DPC 600 decrypts the ECBI image to 
obtain the CBI. In step 812, the DPC 600 uncompresses the 
CBI to obtain the BI. In step 814, the DPC 600 fetches and 
applies the BI template against the BI. Further the DPC 600 

60 divides the BI into image snippets and tags the BI template 
with data capture rules in step 814 to form the Tagged 
Bitmap Image Snippets (TBIS). In step 816, the DPC 600 
submits the TBISs for data capture operations to form the IS 
Derived Data Record (ISDATA). The DPC 600 discards the 

65 TBISs upon completion of the data capture operations in 
step 816. In step 818, the DPC 600 updates the TECBI 
record in the database with the IS Derived Data. 



6,032,137 



21 



22 



In step 820, the DPC 600 determines whether it has 
processed the last TECBI in the TECBI packet. If the last 
TECBI in the TECBI packet has not been processed, the 
DPC 600 extracts the next TECBI from the TECBI packet 
in step 822. Next, control returns to step 806 where the next 5 
TECBI will be processed as described above. 

If the last TECBI in the TECBI packet has been 
processed, the DPC 600 determines whether the last TECBI 
packet has been processed in step 824. If the last TECBI 
packet has not been processed, the DPC 600 fetches the next 10 
TECBI packet in step 826. Next, control returns to step 804 
where the next TECBI packet will be processed as described 
above. If the last TECBI packet has been processed in step 
824, the DPC 600 terminates data processing. 

As is known to persons of ordinary skill in the art, a user 15 
can request information from a relational database using a 
query language. See, e.g., Chapter Three of Database Sys- 
tem Concepts by Korth and Silberschatz. For example, a 
user can retrieve all rows of a database table having a 
primary key with particular values by specifying the desired 20 
primary key's values and the table name on a select opera- 
tion. Similarly, a user can retrieve all rows from multiple 
database tables having primary keys with particular values 
by specifying the desired primary keys' values and the tables 
with a select operation. 25 

The DataTreasury™ System provides a simplified inter- 
face to its retrieval customers to enable data extraction from 
its relational database as described in FIG. 9. For example, 
a DataTreasury™ System customer can retrieve the time, 
date, location and amount of a specified transaction. 30 

The DPC 600 performs data mining and report generation 
for a wide variety of applications by returning information 
from the data base. For example, the DPC 600 generates 
market trend analysis reports and inventory reports for 
merchants by analyzing the data from receipts captured by 35 
the DAT 200. The DPC 600 also can provide important tax 
information to the taxpayer in the form of a report or to tax 
preparation software by retrieving tax information from the 
database which originally resided on receipts, documents 
and electronic transactions captured by the DAT 200. 40 
Similarly, the DPC 600 can also provide tax information for 
particular periods of time for a tax audit. 

FIG. 9 is a flowchart 900 describing the data retrieval 
performed by the DPC 600. In step 902, the DPC 600 
receives a TECBI retrieval request. In step 904, the DPC 600 45 
obtains the customer identifier. In step 906, the DPC 600 
determines whether the customer identifier is valid. If the 
customer identifier is not valid, control returns to step 904 
where the DPC 600 will obtain another customer identifier. 

If the customer identifier is valid in step 906, the DPC 600 50 
will obtain the customer security profile in step 908. In step 
910, the DPC 600 receives a customer retrieval request. In 
step 912, the DPC 600 determines whether the customer 
retrieval request is consistent with the customer security 
profile. If the customer retrieval request is not consistent 55 
with the customer security profile, control returns to step 910 
where the DPC 600 will obtain another customer retrieval 
request. If the customer retrieval request is consistent with 
the customer security profile, the DPC 600 will transmit the 
results to the customer as indicated by the customer security 60 
profile in step 914. 

FIG. 10 is a flow chart describing the use of the DataTrea- 
sury™ system to process checks. In step 1004, the DataTrea- 
sury™ system captures the check at the payer's remote 
location in the preferred embodiment before the payer 65 
presents the check to the payee. Alternatively, the payer 
simply presents or mails the check to the payee. The capture 



of the check at the payer's remote location in step 1004 
enables subsequent comparison of the check as written by 
the payer with the check as received by the payee. In other 
words, this step enables the detection of check alteration 
from fraudulent check schemes where a check is intercepted 
before receipt by the payee and chemically washed to allow 
the perpetrator to work with a blank check. 

In step 1006, the DataTreasury™ system captures the 
check and the payer's biometric data at the payee's remote 
location. In an alternate embodiment, the DataTreasury™ 
system sends electronic transaction data representing the 
check from the payer's remote location to the payer's remote 
location. In step 1008, the DataTreasury™ system performs 
verification of the check and biometric data by comparing 
the remotely captured data with the data stored at a central 
location. The validation further includes checking the cour- 
tesy amount and the payer's signature. 

In step 1010, the DataTreasury™ system determines 
whether the verification was successful. If the verification of 
step 1010 was not successful, the system transmits an error 
message to the remote locations in step 1012 and returns to 
step 1004 for resubmission. If the verification of step 1010 
was successful, the system creates an electronic transaction 
representing the check at a central location in step 1014. The 
electronic transaction representing the check consists of the 
payer bank's identification number, routing information, the 
payer's account number, a payer's check, a payer bank's 
draft, the amount of the check or draft, the payee bank's 
identification number, the payee bank's routing information, 
and the payee's account number. In step 1016, the electronic 
transaction representing the check is transmitted to the payee 
bank. In step 1018, the payee bank transmits the electronic 
transaction representing the check to the payer bank. 

In step 1020, the payer bank verifies the electronic trans- 
action representing the check and determines whether to 
approve a fund transfer. If the payee bank grants approval in 
step 1020, the payer bank transfers the funds from the payer 
bank to the payee bank in step 1022. In step 1024, the 
DataTreasury™ system notifies the payee bank and the 
remote locations as to the status of the transfer. 

While the above invention has been described with ref- 
erence to certain preferred embodiments, the scope of the 
present invention is not limited to these embodiments. One 
skilled in the art may find variations of these preferred 
embodiments which, nevertheless, fall within the spirit of 
the present invention, whose scope is defined by the claims 
set forth below. 

What is claimed is: 

1. A system for central management, storage and report 
generation of remotely captured paper transactions from 
checks comprising: 

one or more remote data access subsystems for capturing 
and sending paper transaction data including a payer 
bank's routing number, a payer bank's routing 
information, a payer's account number, a payer's 
check, a payer bank's draft, a check amount, a payee 
bank's identification number, a payee bank's routing 
information, and a payee's account number, and further 
including subsystem identification information com- 
prising at least one imaging subsystem for capturing the 
checks and at least one data access controller for 
managing the capturing and sending of the transaction 
data; 

at least one central data processing subsystem for 
processing, sending, verifying and storing the paper 
transaction data and the subsystem identification infor- 
mation comprising a data management subsystem for 
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managing the processing, sending and storing of the 
transaction data; and 
at least one communication network for the transmission 
of the transaction data within and between said one or 
more data access subsystems and said at least one data 5 
processing subsystem, with the data access subsystem 
providing encrypted subsystem identification informa- 
tion and encrypted paper transaction data to the data 
processing subsystem. 

2. A system as in claim 1 wherein said one or more data lf) 
access subsystems further comprise at least one scanner for 
capturing the paper transaction data. 

3. A system as in claim 2 wherein said one or more data 
access subsystems also capture electronic transactions from 
credit cards, smart cards and debit cards, signature data or 
biometric data, further comprising: 15 

at least one card interface for capturing the electronic 

transaction data; 
at least one signature interface for capturing an electronic 

signature; and 

at least one biometric interface for capturing biometric 20 
data. 

4. A system as in claim 3 wherein said at least one data 
access controller successively transforms the captured trans- 
action data to a bitmap image, a compressed bitmap image, 
an encrypted, compressed bitmap image and an encrypted, 
compressed bitmap image tagged with information identi- 
fying a location and time of the transaction data capture. 

5. A system as in claim 4 wherein said one or more data 
access subsystems further comprise digital storage for stor- 
ing the tagged, encrypted, compressed bitmap image. 

6. A system as in claim 5 wherein said at least one card 
interface initiates the electronic transaction. 

7. A system as in claim 6 wherein said one or more data 
access subsystems further comprise at least one printer for 
printing the paper transaction initiated by said at least one 
card interface. 

8. A system as in claim 7 wherein the paper transaction 
printed by said at least one printer includes data glyphs. 

9. A system as in claim 1 wherein said data management 
subsystem of said at least one data processing subsystem 40 
comprises: 

at least one server for polling said one or more remote 
data access subsystems for transaction data; 

a database subsystem for storing the transaction data in a 45 
useful form; 

a report generator for generating reports from the trans- 
action data and providing data to software applications; 

at least one central processing unit for managing the 
storing of the transaction data; 50 

a domain name services program for dynamically assign- 
ing one of said at least one server to receive portions of 
the transaction data for balancing the transaction data 
among said at least one server; and 

a memory hierarchy. 55 

10. A system as in claim 9 wherein said at least one server 
also polls for biometric and signature data, said database 
stores the biometric data and the signature data, and said at 
least one central processing unit verifies the biometric data 
and the signature data. 60 

11. A system as in claim 9 wherein said memory hierarchy 
comprises at least one primary memory for storage of 
recently accessed transaction data and at least one secondary 
memory for storage of other transaction data. 

12. A system as in claim 11 wherein said at least one 65 
secondary memory comprises at least one write once read 
many jukebox and at least one optical storage jukebox. 
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13. A system as in claim 12 wherein said at least one 
optical storage jukebox comprises read only memory tech- 
nology including compact disc read only memory form 
factor metallic write once read many disc. 

14. A system as in claim 9 wherein said database sub- 
system comprises at least one predefined template for par- 
titioning the stored transaction data into panels and identi- 
fying locations of the panels. 

15. A system as in claim 14 wherein said data processing 
subsystem further comprises a data entry gateway for cor- 
recting errors in the panels of stored transaction data. 

16. A system as in claim 1 wherein said at least one 
communication network comprises: 

at least one first local area network for transmitting data 
within a corresponding one of said one or more remote 
data access subsystems; 

at least one second local area network for transmitting 
data within a corresponding one of said at least one data 
processing subsystem; and 

at least one wide area network for transmitting data 
between said one or more remote data access sub- 
systems and said at least one data processing sub- 
system. 

17. A system as in claim 16 wherein said at least one 
communication network further comprises: 

at least one modem for connecting said at least one first 
local area network of said one or more data access 
subsystems to a corresponding one of said at least one 
second local area network of said at least one data 
processing subsystem through said at least one wide 
area network; and 

at least one bank of modems for connecting said at least 
one second local area network of said at least one data 
processing subsystem to a corresponding some of said 
at least one first local area network of said one or more 
data access subsystems through said at least one wide 
area network. 

18. A system as in claim 1 further comprising at least one 
data collecting subsystem for collecting and sending the 
electronic or paper transaction data comprising a further 
management subsystem for managing the collecting and 
sending of the transaction data. 

19. A system as in claim 18 wherein said further data 
management subsystem of said at least one data collecting 
subsystem comprises: 

at least one server for polling said one or more remote 
data access subsystems for transaction data; 

a database for storing the transaction data in a useful form; 

at least one central processing unit for managing the 
collecting of the transaction data; 

a domain name services program for dynamically assign- 
ing one of said at least one server to receive portions of 
the transaction data for balancing the transaction data 
among said at least one server; and 

a memory hierarchy. 

20. A system as in claim 19 wherein said memory 
hierarchy comprises at least one primary memory for col- 
lecting transaction data and at least one secondary memory 
for backup storage of the transaction data. 

21. A system as in claim 20 wherein said at least one 
secondary memory comprises at least one DLT jukebox. 

22. A system as in claim 18 wherein said at least one 
communication network comprises: 

at least one first local area network for transmitting data 
within a corresponding one of said one or more remote 
data access subsystems; 
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at least one second local area network for transmitting 
data within a corresponding one of said at least one data 
collection subsystem; 

at least one third local area network for transmitting data 
within a corresponding one of said at least one data 
processing subsystem; and 

at least one wide area network for transmitting data 
between said one or more remote data access 
subsystems, said at least one data collection subsystem 
and said at least one data processing subsystem. 

23. A system as in claim 22 wherein said at least one 
communication network further comprises: 

at least one first modem for connecting said at least one 
first local area network of said one or more data access 
subsystems to a corresponding one of said at least one 
second local area network through said at least one 
wide area network; 

at least one bank of modems for connecting said at least 
one second local area network of said at least one data 
collection subsystem to a corresponding some of said at 
least one first local area network of said one or more 
data access subsystems through said at least one wide 
area network; 

at least one first wide area network router for connecting 
a corresponding one of said at least one second local 
area network of said at least one data collecting sub- 
system to said at least one wide area network; and 

at least one second wide area network router for connect- 
ing a corresponding one of said at least one third local 
area network of said at least one data processing 
subsystem to said at least one wide area network. 

24. A system as in claim 23 wherein said at least one first 
wide area network and said at least one second wide area 
network comprises a carrier cloud, said carrier cloud using 
a frame relay method for transmitting the transaction data. 

25. A system as in claim 22 wherein said at least one 
second local area network and said at least one third local 
area network further comprises a corresponding one of at 
least one network switch for routing transaction data within 
said at least one second local area network and said at least 
one third local area network. 

26. A method for central management, storage and veri- 
fication of remotely captured paper transactions from checks 
comprising the steps of: 

capturing an image of the paper transaction data at one or 
more remote locations said transaction data including a 
payer bank's identification number, a payer bank's 
routing number, a payer bank's routing information, a 
payer's account number, a payer's check, a payer 
bank's draft, a check amount, a payee bank's identifi- 
cation number, a payee bank's routing information, and 
a payee's account number; and sending a captured 
image of the paper transaction data; 

managing the capturing and sending of the transaction 
data; 

collecting, processing, sending and storing the transaction 
data at a central location; 

managing the collecting, processing, sending and storing 
of the transaction data; 

encrypting subsystem identification information and the 
transaction data; and 

transmitting the transaction data and the subsystem iden- 
tification information within and between the remote 
location(s) and the central location. 

27. The method as in claim 26 wherein said managing the 
capturing and sending step comprises the steps of: 
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successively transforming the captured transaction data to 
a bitmap image, a compressed bitmap image, an 
encrypted, compressed bitmap image and an encrypted, 
compressed bitmap image tagged with information 
5 identifying a location and time of the transaction data 
capturing; and 

storing the tagged, encrypted, compressed bitmap image. 

28. The method as in claim 27 wherein said managing the 
capturing and sending step also captures electronic transac- 

io tions from credit cards, smart cards and debit cards, signa- 
ture data or biometric data, further comprising the steps of: 
initiating an electronic transaction; 
capturing signature data; 
capturing biometric data; and 

printing a paper transaction with data glyphs for the 
initiated electronic transaction. 

29. A method as in claim 26 wherein: 

said capturing and sending step occurs at a plurality of 
2Q remote locations; and 

said collecting, processing, sending and storing step 
occurs at a plurality of central locations. 

30. A method as in claim 29 wherein said collecting, 
processing, sending and storing step comprises the steps of: 

25 polling the remote locations for transaction data with 
servers at the central locations; 
storing the transaction data at the central location in a 
memory hierarchy, said storing maintains recently 
accessed transaction data in a primary memory and 
30 other transaction data in a secondary memory; and 
dynamically assigning the servers at the central location 
to receive portions of the transaction data for balancing 
the transaction data among the servers; and 
generating reports from the transaction data and providing 
35 data to software applications. 

31. A method as in claim 30 wherein said storing the 
transaction data step comprises the steps of: 

partitioning the stored transaction data with predefined 
templates into panels; and 
40 identifying locations of the panels. 

32. A method as in claim 31 wherein said managing the 
collecting, processing, sending and storing of the transaction 
data step comprises correcting errors in the panels of stored 
transaction data. 

45 33. A method as in claim 32 further comprising the steps 
of: 

polling the remote locations for captured electronic data, 
captured signature data and captured biometric data 
with servers at the central locations; and 

comparing the captured signature data and the captured 
biometric data to stored signature data and stored 
biometric data respectively for identification verifica- 
tion. 

55 34. A method as in claim 32 wherein said transmitting the 
transaction data step comprises the steps of: 
transmitting data within the remote locations; 
transmitting data from each remote location to a corre- 
sponding central location; and 
60 transmitting data within the central locations. 

35. A method as in claim 34 wherein said transmitting 
data from each remote location to a corresponding central 
location step comprises the steps of: 
connecting each remote location to a corresponding cen- 
65 tral location; and 

connecting each central location to corresponding remote 
locations. 
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36. A method as in claim 29 further comprising the steps 
of: 

collecting and sending the electronic or paper transaction 

data at intermediate locations; 
managing the collecting and sending of the transaction 5 

data; and 

transmitting the transaction data within the intermediate 
location and between the intermediate locations and the 
remote locations and the central locations. 

37. A method as in claim 36 wherein said managing the 
collecting and sending step comprises the steps of: 

polling the remote locations for transaction data with 
servers in the intermediate locations; 

storing the transaction data in the intermediate locations 15 
in a useful form, said storing maintains the transaction 
data in a primary memory of a memory hierarchy and 
performs backup storage of the transaction data into a 
secondary memory of the memory hierarchy; and 

dynamically assigning the servers to receive portions of 20 
the transaction data for balancing the transaction data 
among the servers. 

38. The method as in claim 36 wherein said transmitting 
the transaction data step comprises the steps of: 

transmitting data within the remote locations; 25 

transmitting data from each remote location to a corre- 
sponding intermediate location; 

transmitting data within the intermediate locations; 

transmitting data from each intermediate location to cor- 30 
responding central locations; and 

transmitting data within the central locations. 

39. A method as in claim 38 wherein said transmitting 
data from each remote location to corresponding interme- 
diate locations step comprises the steps of: 35 

connecting each remote location to a corresponding inter- 
mediate location; and 

connecting the intermediate locations to corresponding 
remote locations. 40 

40. A method as in claim 38 wherein said transmitting 
data from each intermediate location to corresponding cen- 
tral locations comprises the steps of: 

connecting each intermediate location to an external com- 
munication network; and 45 

connecting the corresponding central locations to the 
communication network. 
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41. A method as in claim 40 wherein said transmitting 
data from each intermediate location to corresponding cen- 
tral locations step further comprises the steps of: 

packaging the transaction data into frames; and 
transmitting the frames through the external communica- 
tion network. 

42. A system for central management, storage and report 
generation of remotely captured paper transactions from 
checks comprising: 

one or more remote data access subsystems for capturing 
and sending paper transaction data and verifying trans- 
action data from the checks comprising at least one 
imaging subsystem for capturing the checks and at least 
one data access controller for managing the capturing 
and sending of the transaction data; 

at least one central data processing subsystem for 
processing, sending, verifying and storing the paper 
transaction data and the subsystem identification infor- 
mation comprising a management subsystem for man- 
aging the processing, sending and storing of the of the 
transaction data; and 

at least one communication network for the transmission 
of the transaction data within and between said one or 
more data access subsystems and said at least one data 
processing subsystem, with the data access subsystem 
providing encrypted subsystem identification informa- 
tion and encrypted paper transaction data to the data 
processing subsystem. 

43. A method for central management, storage and veri- 
fication of remotely captured paper transactions from checks 
comprising the steps of: 

capturing an image of the check at one or more remote 
locations and sending a captured image of the check; 

managing the capturing and sending of the transaction 
data; 

collecting, processing, sending and storing the transaction 
data at a central location; 

managing the collecting, processing, sending and storing 
of the transaction data; 

encrypting subsystem identification information and the 
transaction data; 

verifying the transaction data from the check; and 

transmitting the transaction data and the subsystem iden- 
tification information within and between the remote 
locations) and the central location. 



